1. Field of the Invention
This invention relates to a method and apparatus for securely transferring objects between crypto modules and, more particularly, to a method and apparatus for transferring such objects as master keys and object protection keys between cryptographic coprocessors of general-purpose computers.
2. Description of the Related Art
Cryptographic functions of a general-purpose computer such as data encryption, digital signature processing and key management have often been performed by a cryptographic coprocessor, both for performance reasons and because of the special security problems posed by the cryptographic environment. One example of a cryptographic coprocessor in an IBM S/390 environment is the Integrated Cryptographic Facility (ICRF). ICRF was used with processors employing bipolar technology. With the migration to CMOS processor technology, as exemplified by the S/390 Parallel Enterprise Server, new technological challenges have arisen in the design of a cryptographic coprocessor that is optimized for a CMOS setting.
In an environment where reliability, availability, and serviceability are important, it is necessary to provide for multiple parallel systems which can be used to assist in throughput, backup, and recovery. For most types of equipment, this can be accomplished by providing several units, all of which are interchangeable. With cryptography, this presents a problem, since some of the information in a particular cryptographic processor (e.g., a cryptographic coprocessor of a general-purpose computer) must be kept secret. This is true, in particular, for master keys. Many customer environments require the master keys for all production systems to be the same.
In most cases, master keys are derived from information from several sources. For installation of a new system it will usually be possible to arrange for all parties having the component parts to be available to enter the particular parts. But for installation of a replacement cryptographic processor this may not be the case. In these cases, it is desirable to have a way to transfer the master key from one cryptographic processor to another.
In some cases, the master key information could be the result of random, or pseudorandom, information and is not known to anyone outside of the system. In these cases, it is necessary to have a way to transfer the master key from one cryptographic processor to another.
When PKA (public key algorithm) private keys are used by a cryptographic processor, the private key is protected in the form of an encapsulated object. There may be situations in which the same private key needs to be available to multiple systems. This could be the case for purposes of performance or availability. The problem is, how to provide a hardware-controlled mechanism to permit a secure transfer of an encapsulated object from one system to another.
The following methods have been provided in the past:
1. The systems share the same cryptographic processor. PA1 2. The systems share a common master key. PA1 3. The private key is protected by an object protection key and the object protection key is shared by the systems. PA1 4. The private key is converted to an external form, encrypted under a shared key, transmitted from one system to the other, and then converted from the external form to an internal form. PA1 1. Reencipher From SMK PA1 2. Reencipher From RMK PA1 3. Reencipher To SMK PA1 4. Reencipher To RMK
The first alternative listed above does not provide availability or performance. The first two alternatives provide no granularity of sharing; the two systems either share everything or nothing. In many cases, it will be required that some, but not all, private keys need to be available on two systems. Alternatives 2-4 require a preestablished shared secret before this secret can be shared. Alternatives 3 and 4 have never been provided in the past with multiple control.
A cryptographic processor must provide for the secure entry of key parts for the master key and also for operational keys. One possible approach is to use an RSA key on the cryptographic processor for both authentication and protection of secret information sent to the cryptographic processor. However, the RSA secret exponent may be burned into the cryptographic processor and not erased if the cryptographic processor is removed from the system. Thus, if after the cryptographic processor has been used for some time, it fails, is sold or is stolen, it is possible that the cryptographic processor chip can be opened and inspected to reveal the RSA secret exponent. Knowledge of this RSA secret exponent could then be used to decrypt any secret information previously encrypted using the public key of the cryptographic processor.
The use of the Diffie-Hellman (DH) key agreement procedure to establish a shared secret is well known in the art, and software-only versions abound. But splitting this function up between hardware functions inside a secure boundary and a software program which resides outside of this boundary is a nontrivial problem.